Traditional alarm systems have been of the “dialup” variety. When an alarm (or other) condition occurs in the home or business, the alarm panel dials up a remote monitoring station or middleware provider or other monitor, based on a pre-programmed phone number stored in the alarm system memory. Once the connection is made, the alarm or other condition is transmitted to the monitor using DTMF (Dual Tone, Multiple Frequency) signals to indicate the source of the alarm or other signal and the type of alarm or other signal. The alarm or other signal may include burglary, fire, water intrusion, glass break, alarm set and reset, maintenance, and other signals generated by the alarm system located on the premises.
The dialup systems suffer from a number of faults, not the least of which is the problem that the system “seizes” the phone line when an alarm condition occurs, and as a result, prevents the alarm user from calling in a false alarm or the like. In addition, these prior art “dialup” alarm systems are programmed to work with a POTS (Plain Old Telephone Service) line, and not any of the new types of phone services, such as VoIP, Vonage, Skype, cellular, and the like. A further fault is that the systems are generally programmed to dial out to a number programmed into the system, making it difficult for the consumer to change monitoring providers and the like.
Methods and apparatus have been developed for modifying such alarm systems to work with other monitoring providers, middleware providers, and the like, and reference is made to applicant's prior applications previously incorporated by reference. In addition, methods and apparatus for using broadband communications to monitor alarm systems, either through VoIP broadband links or by interfacing the alarm system directly to a broadband connection, are also disclosed in the aforementioned applications previously incorporated by reference.
In many areas, however, broadband is not available, either as DSL (Digital Subscriber Line) or by Cable Modem or other means (e.g., wireless broadband, cellular modem, and the like). Thus, high-speed Internet users may have to resort to a satellite link to obtain a broadband Internet connection. DirectWay, now HughesNet, is probably the best known of these satellite service providers. While satellite broadband provides a service almost equivalent to DSL or Cable Modem broadband, in terms of speed, there are some inherent differences in the technologies which make satellite broadband different.
Since satellite broadband relies on the use of a geo-synchronous and geo-stable satellite, in fixed orbit about 22,233 miles from the surface of the earth, there is a time delay between when a signal is sent from an uplink at either end, and when it is received by the downlink at the other end. At the speed of light, this delay would amount to about 0.2 seconds, round trip, although other links in the Internet add additional delays as well. Thus, some broadband applications may not work or work well with satellite broadband communications. For example, when testing the Vonage® broadband VoIP communications system over a HughesNet satellite link, it was noted that while the system could be made to work for brief periods, there were time delays on the order of a second or more.
Moreover, as satellite broadband is an asymmetrical data link (like most DSL), the uplink data path from the consumer is much smaller (on the order of 56K dialup) than the downlink (on the order of DSL) from the service provider. In addition, atmospheric conditions (clouds, rain, and the like) can severely limit or cut off satellite broadband communications entirely. Again, when attempting to text a Vonage® box on a Hughesnet connection, it was possible to connect brief calls. However since the uplink bandwidth is so narrow, the signal from the subscriber was garbled and incoherent, while the return path signal was at least understandable.
Prior Art alarm systems are generally designed using one or more an industry standard protocols. Ademco® is one of the largest maker of alarm systems, and uses a common set of alarm protocols for most of its alarm systems. One of these is the Ademco® Contact ID Protocol, described in the document Digital Communication Standard—Ademco® Contact ID Protocol for Alarm system Communication” SIA DC-04-1999.09, Security Industry Association, © 19999, Publication Order Number 140-85, incorporated herein by reference. Many other alarm makers use similar or identical protocols or offer compatibility with the Ademco® Contact ID protocol.
FIG. 2 is a block diagram illustrating the main steps in the operation of the Contact ID Protocol. Once an alarm or other condition occurs in step 200, the alarm system dials out to a pre-programmed phone number. Once the call is completed and the alarm monitor “picks up” a handshake is generated an detected in step 210 comprising a tone of 1400 hz for 100 ms, then silence for 100 ms, and then a tone of 2300 hz for 100 ms. The alarm system then waits for an acknowledge tone for a period of about 1.25 seconds. This acknowledge tone may comprise a 1400 hz tone generated for 400 ms. Once the handshake and acknowledge tone are exchanged, the system waits until the end of the tones in step 220. After a delay of 250 milliseconds in step 230, the alarm system and monitor may communicate via DTMF tones, for example, a 4 digits account code, a 2 digit alarm code, and then a checksum code or the like in steps 240 and 250.
Each message is searched for the presence of the “kiss-off” tone in step 260 to determine whether the communication is complete. If the kiss-off tone is detected in step 270, a determination is made in step 280 whether more messages are to be exchanged. If yes, processing returns to step 220. If not, processing proceeds to step 290, the phone connection is broken and the process ends in step 300. If no kiss-off is received in step 270, and the increment attempt count is greater than four, as determined in step 275, the call is ended. If not, processing returns to step 250 and a message transmission is attempted again.
Transmission of DTMF alarm codes themselves may not present much of a problem using VoIP connections on satellite broadband. However, due to the time delays mentioned above, the handshake and acknowledge codes may not function properly, as the time period for the acknowledge tone may “time out” before the tone is received. Thus, broadband applications such as alarm systems over VoIP or alarm systems using direct broadband connections may not operate properly when used over a satellite broadband communications link.